昨天已經完成「AI 避雷探針」的首頁，使用者可以輸入店家名稱，並透過 JavaScript 進行基本的按鈕互動。
不過，首頁只是使用者開始使用網站的地方，真正分析完成後，最重要的還是要讓使用者看到一份容易閱讀的「避雷報告」。
所以今天先來設計分析完成後的報告頁面。

今天要做什麼？

今天先使用假資料，把之後 AI 分析完成後的畫面做出來。
這樣可以先確定：
報告頁面要有哪些內容
不同分析項目要怎麼排列
使用者閱讀起來是否清楚
避雷報告要顯示什麼？
根據 Day 9 設計好的分析項目，目前預計將報告分成以下幾個部分：

• 整體評價
• 可能的雷點
• 餐點／服務
• 環境
• 價格
• 等待時間
• 疑似罐頭評論／異常評論
• 評論參考度
  另外，如果評論中有提到評論送贈品、評論送優惠或其他可能影響評論的活動，也會另外顯示。

使用假資料測試

為了先完成頁面，今天先假設 Gemini 已經分析完一家店。
例如假設分析結果是：

店家名稱：

某某拉麵店

整體評價：

整體評價偏正面，大部分評論對餐點有不錯的評價。

可能的雷點：

尖峰時段可能需要等待
部分評論提到服務速度較慢

餐點／服務：

餐點評價大多正面，但部分評論提到出餐速度較慢。

環境：

部分評論提到環境整潔，整體用餐空間評價普通。

價格：

部分評論認為價格偏高。

等待時間：

有評論提到尖峰時段需要等待。

評論異常特徵：

部分評論內容較短，另外有少數評論使用相似的描述。

評論參考度：

需要多留意
這些內容目前只是測試網站畫面用的假資料，並不代表實際店家的分析結果。

和 Day 12 JSON 的關係

今天做報告頁面時，也開始把 Day 12 設計的 JSON 和網站畫面連結起來。
之前 JSON 設計的是：
overal l對應：整體評價
risk_points 對應：可能的雷點
food_service 對應：餐點／服務
environment 對應：環境
price 對應：價格
waiting_time 對應：等待時間
suspicious_review 對應：評論異常特徵
review_reference 對應：評論參考度
這樣未來 Gemini 產生 JSON 後，JavaScript 就可以把不同欄位的資料放到對應的網頁區塊。

為什麼先使用假資料？

今天先使用假資料，是因為如果同時處理：
Google Maps API
Gemini
JSON
JavaScript
網頁畫面
遇到問題時會很難知道是哪一個部分出錯。
所以目前採用一步一步完成的方式：
先完成首頁
↓
再完成避雷報告畫面
↓
確認畫面可以正常顯示
↓
再串接 JSON
↓
最後再串接 Google Maps / Places API 和 Gemini
這樣之後如果 AI 的資料沒有正確顯示，就可以比較容易找到問題。

版面設計

為了讓使用者可以快速閱讀，我把不同的分析項目分成一個一個的資訊卡片 ，讓每個分析項目都有自己的區塊，這樣可以讓資訊比較集中，也方便之後直接將 JSON 裡不同欄位的內容放到對應的區塊。 。

實際執行畫面

今天先使用假資料完成避雷報告頁面，測試使用瀏覽器開啟網站，確認假資料是否可以正常顯示。

今天的學習

今天開始製作「AI 避雷探針」真正的分析結果頁面。
我發現網站不只是要把資料顯示出來，還需要思考怎麼整理，才能讓使用者快速找到自己想看的資訊。
因此，我把之前 Day 9 規劃的分析項目，整理成不同的報告區塊。
今天先使用假資料完成畫面，之後再逐步把假資料換成真正的 AI 分析結果。